2026-09-19-[Jev-Review]-텍스트 대신 결정을 내는 모델 Jev 핸즈온

텍스트 대신 결정을 내는 모델, Jev 핸즈온 후기

TL;DR

• Jev는 TypeSafe AI의 첫 "System One" 모델로, 문장을 생성하는 대신 타입이 정해진 결정을 반환한다.
• 콘솔에서 State(맥락)와 Questions(타입 질문)를 넣으면 각 답이 확률·선택·점수로 나온다(Choice·Score에는 confidence도 붙는다).
• 응답은 실측 116~158ms로 빠르고, 한 호출에 여러 판정을 병렬로 담을 수 있다.
• 역할은 생성 옆에서 판단·게이트하는 System 1 레이어다(생성 자체는 LLM 몫).
• "환각 불가"는 타입 보장이지 정답 보장은 아니다.
• 성능·비용 수치는 아직 벤더 자체 측정이다.

Jev의 정체

TypeSafe AI(창업자 Diogo Almeida, 전 OpenAI)가 2026년 9월 공개한 첫 "System One Model"이다. "System One"이라는 분류명은 Kahneman의 『Thinking, Fast and Slow』에서, 모델명 "Jev"는 경제학자 William Stanley Jevons에서 왔다. 빠르고 직관적인 시스템 1과 느리고 숙고적인 시스템 2 중 Jev는 시스템 1을 겨냥한다. 기존 LLM이 사람과 대화하려고 문장을 짓는다면 Jev는 소프트웨어가 바로 쓸 결정을 내린다. 벤더의 한 줄 표현으로는 "비정형 상태가 들어가고 타입이 정해진 확률적 결정이 나오는 함수 호출"이다.

Jev는 사람이 규칙을 직접 짜놓은 시스템이 아니다. 벤더 설명상 새 아키텍처와 RLCD(Reinforcement Learning for Calibrated Decisions, 보정된 결정을 위한 강화학습)로 학습한 모델이고 state와 question의 관계는 학습으로 형성된다. reasoning trace를 글로 남기지는 않아도 내부 계산은 일어난다. 빠르고 값싼 이유는 출력을 한 번에 병렬로 내는 구조에 있다. 일반 LLM은 토큰을 하나씩 이어 붙이며 여러 번 계산하지만 벤더 설명대로면 Jev는 state와 question을 받아 decision을 바로 출력한다.

콘솔에서 써본 첫인상

플레이그라운드는 왼쪽에 두 개의 JSON을 채우고 Run하는 구조다. State에는 판단 대상 맥락을, Questions에는 묻고 싶은 것을 타입과 함께 적는다.

질문 타입은 셋이다.

• Noul: 명제가 참일 확률. "핫도그는 샌드위치인가?" 같은 물음에 0.58 같은 확률을 매긴다. (이름은 공식 정의가 없고 외부 해설은 "no"+"null" 합성어로 본다.)
• Choice: 여러 선택지에 대한 확률 분포.
• Score: 루브릭 점수. 레벨 분포의 기대값이다.

챗봇과의 차이: 답 대신 분포

가장 인상적인 화면은 Choice였다. "하늘색은 무슨 색?"을 State "토네이도 임박"과 함께 물으면 답이 한 단어로 나오지 않는다.

토네이도가 오는 하늘은 녹색을 띠는데 모델이 그걸 반영해 seafoam green에 확률을 몰았다. 소프트웨어는 이 분포를 받아 임계값·가중치 로직을 바로 짤 수 있다. 일반 챗 인터페이스였다면 "초록빛이에요"처럼 한 문장으로 답했을 것이다. 게다가 답마다 confidence가 따로 붙는데 이건 "가장 유력한 값의 확률"과 "이 결정을 믿어도 되는 정도"를 나눈 값이다.

한 호출로 여러 판정

Jev는 한 요청에 질문을 여러 개 묶을 수 있다. LLM 가드레일 예시가 이걸 잘 보여준다. 전형적인 탈옥 프롬프트(DAN)를 넣으면 한 번에 세 판정이 나온다.

어느 정책을 위반했는지(Choice), 탈옥 시도인지(Noul 98%), 응했을 때 얼마나 위험한지(Score 1.69/3)가 각각 confidence와 함께 나온다. 지연은 158ms 남짓이었다. 사람 리뷰어의 체크리스트를 함수 호출로 옮긴 듯하다.

Jev의 역할: 생성 옆의 System 1 레이어

써보면서 분명해진 건 Jev가 LLM과 경쟁하지 않는다는 점이다. Jev는 결정을 내릴 뿐 글을 쓰거나 코드를 짜지는 않는다. 실무에선 Jev와 LLM을 함께 쓰는 "Jev + LLM" 구성이 자연스럽다. Kahneman의 비유를 빌리면 Jev는 빠른 판정을, LLM은 느린 생성을 맡는다.

에이전트나 코드 파이프라인에서 Jev가 들어갈 자리는 크게 셋이다.

• 에이전트 루프 안에서 다음 액션·분기를 빠르게 고르는 판단 노드
• LLM 입출력에 대한 가드레일(프롬프트가 탈옥인가, 출력이 규격에 맞나)
• 값싼 1차 필터. 대부분을 Jev가 처리하고 confidence 낮은 것만 사람·대형 모델로 넘긴다

하네스 관점에서 보면 "느리고 비싼 LLM에게 판단까지 맡기던 자리"를 타입 안전한 결정 함수로 떼어내는 그림이다.

쓰임새

커뮤니티에 이미 여러 사례가 올라왔다(Threads 정리 기준, 수치는 원 게시자 주장이라 미검증). 크게 두 갈래다.

• 대량 판정: 논문 수천 편 주제 분류, 광고 수백 개 검수, 이력서 심사, PR 자동 검토. 한 건씩의 결정을 데이터 전체에 병렬로 반복한다.
• 실시간 루프: 브라우저 에이전트의 다음 액션, 게임 플레이, 온체인 트레이딩. 매 스텝 "다음 선택"을 낮은 지연으로 정한다.

콘솔에서 이력서 심사 예시를 돌려보니 가상 지원자 한 명에 경력·기술 깊이·멘토십·인재 유형 등 일곱 항목이 각각 점수와 confidence로 한 번에 나왔다.

주의점

• 타입 안전이 정답을 보장하지 않는다. 스키마에 맞는 값이 나오는 것과 그 값이 맞는 것은 다르다. 유효하지만 틀린 선택은 여전히 가능하다.
• Score는 레벨 인덱스다. 예시에서 경력 점수 2.99는 "2.99년"을 뜻하지 않는다. 확률이 레벨 3("6 years")에 몰린 값이다. legend와 함께 읽어야 한다.
• 성능·비용 수치는 벤더 자체 측정이다. 지연과 스키마 강제는 콘솔에서 체감했지만, 속도·비용 배수와 보정 정확도는 독립 검증이 아직 없다. 내 관측도 모두 1회짜리다.

한 줄 정리

Jev는 글을 잘 쓰는 모델이 아니다. 결정을 빠르고 타입 안전하게 내는 함수다. 생성 작업은 여전히 LLM이 맡고 Jev는 그 옆에서 소프트웨어가 의존할 판단을 담당한다.